Research Problem

The Smart Service Discovery and Composition tool enables the automation of BPaaS allocation which is currently manually performed by the BPaaS broker. The BPaaS broker is currently faced with a two faced problem: (a) how to discover those services which are able to either realise the functionality of the BPaaS workflow service tasks or support the execution of the internal software components of these tasks; (b) how to select the best alternative from the service candidates of each task such that the user requirements at both the global and local level are optimised.

Concerning the first problem, the current state-of-the-art focuses on providing solutions on just one aspect, either the functional or the non-functional one. In many cases, the respective techniques do not exploit the service semantics. In addition, the alignment of QoS terms is usually not considered in non-functional service matchmaking. These two issues lead to low precision and recall in the service discovery process. Moreover, the execution time and the scalability of the respective discovery algorithms are usually not satisfactory due to the non-exploitation of smart techniques which attempt to cleverly organise the service advertisement space.

As far as the second problem is concerned, we need first to explicate that the service selection problem in BPaaS allocation is usually harder with respect to the selection of SaaS or IaaS services. This is due to the fact that both IaaS and SaaS selection are inter-dependent on each other. This means that the selection of an IaaS service can have an effect on the QoS at the SaaS level which can then influence the service selection at this latter level. As such, there is a need for an approach which is able to select both IaaS and SaaS services in conjunction by still taking into account all types of user requirements.

Secondly, by focusing on individual level service selection, the proposed approaches usually exhibit various issues which include the following: (a) the dependencies between the different QoS terms are not considered; (b) pessimistic or average approach over service graph and available solution space is employed; (c) just a single value and not ranges of QoS values are considered to cater for the suitable service description in dynamic environments; (d) no solution is returned for over-constrained user requirements.

Solution Approach

The Smart Service Discovery and Composition tool enables both the semantic discovery of cloud services at different levels of abstraction as well as the concurrent selection of both SaaS & IaaS services for service-based workflow concretisation according to the broker functional and non-functional requirements.

The tool actually comprises two main modules dedicated to cloud service discovery and selection, respectively. As such, the respective feature presentation is done per each main module of this tool.

Concerning service discovery, the main features of the blueprint can be summarised as follows:

- Supports both functional and non-functional semantic service discovery to cover all possible aspects in service description. The functional aspect is covered by OWL-S while the non-functional one by OWL-Q.
- Smart service discovery is offered which enables boosting the service matchmaking time. Smartness is realised at two levels: (a) the transactional combination of aspect-specific matchmakers according to different composition semantics (currently parallel composition maps to the fastest implementation); (b) at the individual, aspect-specific level, each service matchmaker utilises smart structures in order to better organise the service advertisement space and accelerate the service matchmaking.
- The tool enables not only the matchmaking but also the management (update, insertion, deletion) of the functional and non-functional service specifications.
- A Java and REST API are offered to enable the service discovery and service specification management.

As far as service selection is concerned, the respective module exhibits the following features:

- concurrent selection of both IaaS and SaaS services to deliver purely optimal selection solutions for the service-based BPaaS workflow.
- catering also for different realisation alternatives for a SaaS service: (a) either an external SaaS service can be exploited or (b) an internal one which also requires being hosted in a public or private cloud. In the latter case, the internal service code would be either purchased or has been developed internally by the broker organisation.
- consideration of a great variety of non-functional requirements, including performance and reliability ones (over, e.g., response time, throughput, availability and reliability), security ones at both a coarse (in terms of security controls) and a fine-grained level (in terms of security SLOs) and cost. 
- capability to map low-level non-functional capabilities to higher-level ones in the form of dependency functions to cover any dependency gap within the respective optimisation problem.
- capability to handle both linear and non-linear constraints as well as both real and integer-based variables (mapping to the coverage of the previous functions as well as aggregation ones over non-functional metrics (from component/service to application/workflow level)).
- in case that a specific time deadline has to be provided, the respective solver can be configured to take it into consideration, thus being able to more rapidly produce solutions with a potential penalty over solution optimality.

Architecture

The source code is publicly available at GitLab.

Try out the first version of the prototype by yourself: DMN-to-CAMEL-Mapper service

References

• D3.3 - BPaaS Allocation and Execution Environment Blueprints
• D3.4 - BPaaS Allocation and Execution Environment Prototypes